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ABSTRACT 

Over the past 4 years the Component Systems and 
Hardware branch at NASA GSFC has pursued an in- 
house effort to build a unique space-flight GPS receiver. 
This effort has resulted in the Navigator GPS receiver. 
Navigator’s first flight opportunity will come with the 
STS- 1 25 HST-SM4 mission in August 2008. This paper 
covers the overall hardware design for the receiver and 
the difficulties encountered during the transition from the 
breadboard design to the final flight hardware design. 

Among the different lessons learned, the paper stresses 
the importance of selecting and verifying parts that are 
appropriate for space applications, as well as what 
happens when these parts are not accurately characterized 
by their datasheets. Additionally, the paper discusses what 
analysis needs to be performed when deciding system 
frequencies and filters. The presentation also covers how 
to prepare for thermal vacuum testing, and problems that 
may arise during vibration testing. It also contains what 
criteria should be considered when determining which 


portions of a design to create in-house, and which 
portions to license from a third party. 

Finally, the paper shows techniques which have proven to 
be extraordinarily helpful in debugging and analysis. 

INTRODUCTION 

This design resulted from a series of developments and 
opportunities. 

In 2001, Moreau researched and defined the capabilities 
which a robust space-flight GPS receiver would require 
[1]. This work both listed the limitations of space-flight 
GPS receivers available at the time and discussed 
techniques that could increase the maximum operational 
altitude of a GPS receiver to include above-the- 
constellation geosynchronous and highly elliptical orbits. 

Dr. Moreau used the PiVoT GPS receiver, developed at 
GSFC, in hardware-in-the-loop simulations to provide 
hard data to support his analyses. Like many receivers at 
the time the PiVoT receiver was based on the 
GP2010/GPS2021 chipset. Having no frequency domain 
correlation capability, the receiver relied on a sequential 
search to acquire GPS signals. 

In 2002, Wintemitz [2], at NASA GSFC, mapped out a 
means to use the results of Psiaki’s research at Cornell 
University [3]. This new hardware would incorporate a 
frequency domain correlation engine to perform weak 
signal acquisition. It would also move away from the 
commercially available correlators towards an in-house 
tracking design. This new design would be implemented 
in radiation hardened FPGAs. The goal was to achieve an 
acquisition and tracking threshold of 25 dB-Hz. 

The design was built and debugged on a Xilinx based 
breadboard, provided by General Dynamics. An RF front 
end was constructed from a signal generator and a chain 
of discrete components. Using this design, the algorithm 


and the system were proven. The team was successfully 
able to acquire and track GPS signals down to 25 dB-Hz. 

In 2003, the Navigator team began working with the 
Magnetospheric Multiscale (MMS) Mission to develop a 
custom GPS receiver with an integrated S-band 
transceiver. The mission consists of four satellites 
designed to measure magnetic field variations. Each 
satellite needs to know its own position, as well as the 
distances between itself and each of the other satellites. 
Additionally, each satellite needs to send a science quality 
index to the other satellites. This combined position and 
messaging feature was referred to as the Inter-satellite 
Ranging and Alarm System (IRAS). 

Because Navigator and IRAS were new technologies, 
MMS required that both be proven out as early as 
possible. In an effort to meet MMS’s requirements, the 
Navigator team began putting together a list of parts that 
could meet the radiation, vibration, and power thresholds 
which would be seen during the life of the mission. There 
was the desire to expose the combined GPS and IRAS 
system to the space environment before the 2012 launch 
date, but no formal opportunity was presented at the time. 

The team also began designing a system to emulate the 
path delays and Doppler shifts seen by the satellites as 
they received each others’ messages. This system has 
become known as the PERFS (Path Emulator for RF 
Systems) project. 

In 2005, members of the Hubble Space Telescope’s fourth 
Servicing Mission (Hubble SM-4) offered a space flight 
opportunity to perform a bi-static ranging demonstration 
as part of the Relative Navigation Sensor (RNS) 
experiment. The desire was to verify if the team could use 
the weak signal GPS acquisition and tracking ability of 
the Navigator to provide relative navigation solutions 
between the Hubble and the space shuttle. 

This would be accomplished by using the concept of bi- 
static ranging [4]. Using direct measurements from the 
GPS constellation and weak reflected signals off of the 
Hubble, the team plans to passively estimate the relative 
position of the two vehicles. 
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Figure 1: GPS Relative Navigation Concept 

Based on pseudo-ranges p D j rec t, and Phst +p re iative from 
multiple visible satellites, Navigator needs to provide 
Preiative for the SM-4 mission. 


The launch date for Hubble SM-4 was September 2008 
(and has since been moved to August 2008). This 
opportunity came at a perfect time. A substantial amount 
of research into parts selection had already been 
performed. Now it needed to be implemented on an 
accelerated schedule. Wherever possible, the team tried to 
make the SM-4 and GPS+IRAS designs common. This 
would maximize the validation of the GPS design. 


DESIGN REQUIREMENTS 


Table 1 describes some of the design requirements levied 
by the MMS and SM-4 missions [5]. In the cases of 
differing values (between the two missions), the more 
stringent value is used in the table. 


Requirement 

Power limits 

Mass 

Power source 

Vibration 

Temperature (on and off) 

Depressurization rate 

Contamination (off-gassing) 

Radiation (SEU) 

Radiation (Total Dose) 

Physical (overall) 


GPS Accuracy (MMS) 

GPS Accuracy (SM-4) 

Table 1: Design Requirements 


Threshold 

30 W 

21 lbs 

24 to 32 Volts DC 

14.1 G rms 

-30° to +60° C 

0.445 (psi/sec) 

lpg/cm 2 

37 MeV-cnr/mg 

lOOk-rad (Si) 

Should create no threat 
to astronauts. Space 
Shuttle or Telescope 
30 m to 35 km, based on 

mission phase 

No Requirement 
i for Navigator Receiver 


In the process of verifying the mission requirements, 
failures were discovered. The following sections describe 
what is the over-all design of the system, how the team 
discovered each failure, how each failure was traced back 




Figure 3: Acquisition Blocks and Debugging Mux 


Several errors were discovered by observing the signals 
between and inside the functional blocks. These include 
biases in the ADCs, logical errors, rounding asymmetries, 
state machine errors, unexpected counter overflows, and 
I/O errors. A logic analyzer was used for immediate 
debugging and also to store data to a file for processing. 

Lesson Learned: 

Simulating VHDL is always the best method of finding 
bugs, however there are times when bugs only appear 
after a large amount of data has passed through the 
system. For such cases, it is important to be able to easily 
debug hardware in the lab using logic analyzers. 

SOLDER BRIDGES ON SRAM 

During the initial unit test of any system, the boards must 
be analyzed to discover any manufacturing related errors. 
Possible errors can include electrical shorts between 
power and ground, or between unrelated signals. They can 
include components that are not placed properly (either 
skew, or 90 degrees out of orientation), components that 
are not completely soldered down, components which are 
absent. The initial test also ensures that the required 
voltages in the system are correct and within prescribed 
tolerances. 

Some aspects of the initial unit test can be automated, to 
save time and increase reliability. Some such tests are 
memory verification and connectivity tests. Other aspects 
can not be automated, such as finding the cause of a new 
type of failure. 

On the Navigator, the acquisition SRAM connects to the 
acquisition FPGA and contains the coherent and non- 
coherent GPS correlations. Whenever power is applied, 
the acquisition FPGA writes a unique pattern to each 
address in the SRAM, and then reads it back. During the 


read-back, the FPGA maintains statistics about how well 
the SRAM performed, such as: how many addresses 
failed, where was the first failure, and which data-bits 
failed. This gives the testing engineer a starting point in 
debugging most common connectivity problems. 

The day that the team performed the initial unit test of the 
Navigator board, two sets of unrelated pins were failing. 
Many of the pins were address pins. This was causing 
data contents to be written in the wrong memory location. 


board traces 



solder bridge 
(beneath SRAM) 


Figure 4: Location of a solder bridge 

Upon reading the statistics registers, the test engineer 
knew to look more closely at the pins of the SRAM. It 
was discovered that solder had splashed under the body of 
the SRAM and “bridged” (connected) two unrelated pins. 
This can be seen in Figure 4. Due to the location of the 
solder bridge, it was difficult to see unless an inspector 
knew that it was there. Because of the self testing 
mechanism, the problem was caught quickly and early in 
the development process. 

If the problem had gone undetected, it would have caused 
erroneous acquisition results. Because the bridge caused 
two pins to be shorted together, it would likely have 
reduced the life span of the Acquisition FPGA which was 
commanding those pins. 

Lessons Learned: 

Connectivity errors are fairly common in development 
systems. It is generally easy to implement circuitry or 
software to perform basic connectivity tests. They are 
well worth the investment. 

POWER SPECTRAL DENSITY SPURS 

This was the most interesting problem the team faced. 

The team had finished verifying the RF Daughtercard in 
conjunction with the strong signal functionality of the 
Navigator motherboard. It was time to begin verifying the 
weak signal acquisition mode. 















We then ran several tests at 30 dB-Hz and initially were 
not able to acquire the signals. The first observed 
symptom was that the forward FFT began overflowing. 
This made the team think that there was a strong in-band 
signal that was getting to the ADC. 

The team needed to isolate whether the problem was on 
the digital Navigator motherboard, on the analog RF 
Daughtercard, or in the low noise amplifier (LNA). The 
RF Daughtercard was disconnected and the discrete RF 
chain was reconnected to see if the problem was still 
present. The problem had gone away. The team was able 
to acquire the weak signal, with no problem. 

The RF Daughtercard was reconnected. Digital samples 
of the I/F signal were taken at the Analog to Digital 
Converter (ADC) and stored to a file using a digital logic 
analyzer. When the samples were analyzed, spurs were 
seen in the power spectral density (PSD) plot. This 
showed that there was a signal that was getting into the 
RF or IF chain. Due to the 8. 192 MHz sampling, we could 
only see the aliased frequency of the unwelcomed signal. 




Figure 5: Location of unwanted spurs on PSD chart. 

Using an oscilloscope, the inputs to the amplifiers in the 
RF chain were checked for any signals above the noise 
floor, but none were visible. Next, beginning with the first 
amplifier in the RF chain (this is the amplifier which 
receives the RF signal from outside of the box), a team 
member connected the input of the amplifier to ground. 
The theory was that grounding the input to an amplifier 
should show if the in-band signal is upstream (closer to 
the LNA) or downstream (closer to the ADC) of the 
amplifier under test. If grounding the input removed the 
spurs from the PSD, then the in-band signal should be 
upstream. 

Grounding the first amplifier reduced the relative height 
of the peak over the noise floor, but did not eliminate it. 
Grounding the input to the second reduced the spur’s 
relative height more, but also reduced the noise floor. 


Grounding each amplifier’s input to ground resulted in the 
reduction of the relative peak of the spur, until the last 
amplifier in the chain was grounded. At that point there 
was no spur and no detectable signal at all. It was 
determined that no single amplifier was introducing the 
unwelcomed signal. Each one appeared to be contributing 
to it. 

Because the spurs only occurred with the RF 
Daughtercard (and not with the discrete chain located on 
the bench top), the team wanted to determine if there was 
a signal radiating from the motherboard. In order to verify 
this, all the components would need to be turned off or 
removed from the motherboard. Luckily, the board design 
included a clock distribution tree which provided a 
dedicated clock signal to each component. Because of this 
conservative design technique, turning off each active 
component was an achievable goal. 

Additionally, because the design was being ported and 
debugged, the team used sockets to hold each of the 
FPGAs on the board. This allowed those chips to be 
removed easily. For the other digital components, their 
clock was removed at the board’s clock driver. By 
removing c locks to each of the digital components, one by 
one, and inspecting the PSD, the team was able to search 
for a possible aggressor. The only component which 
caused the PSD spurs to go away was the ColdFire 
microprocessor itself. 

Now that the team had a suspect, they needed to 
characterize what aspect of the microprocessor was 
causing the spurs. The team’s RF designer connected a 
coaxial cable to an amplifier and connected the output of 
the amplifier to a spectrum analyzer. This was done to 
create an “RF Sniffer.” The open end of the coaxial cable 
was covered with kapton tape to prevent accidentally 
shorting any pins on the processor. The engineer then 
used that open end of the cable as a hand-held antenna. 
This antenna was passed over the processor chip to see if 
there were pins which were acting as aggressors. 



Certain signals were creating a significant amount of RF 
noise as seen on the spectrum analyzer. When pins on one 
side of the processor were probed with an oscilloscope, it 
was discovered that there were spurs. 

The captured image in Figure 7 shows the voltage on an 
output pin as a function of time. This signal should be a 
constant 3.3 volts, however it has recurring spurs that 
drop down to 2.96 volts. These fast changes create noise. 


RF Daughtercard Navigator Motherboard 


RFO RF1 



ColdFire 



Figure 7: Voltage Spurs on the ColdFire scan-out pins. 

The signal displayed in Figure 7 should be constantly 
high at 3.3 volts. The clock input to the processor is 
65.536 MHz, and gets divided by two inside the processor 
to create a bus clock of 32.768 MHz. It appears that there 
are two overlapping sets of spurs, which occur at the 
slower clock frequency. The spurs last only 1-2 
nanoseconds from the beginning of their drop to their 
return to the nominal 3.3 volts. Each spur seen has a 
magnitude of approximately 0.3 volts. 

The peaks were occurring at a frequency of approximately 
65.536 MHz. The team observed the harmonics of this 
frequency on the spectrum analyzer. The 24 th harmonic of 
this frequency is 1.57286 GHz, and the LI C/A code 
signal is located at 1.57542 GHz. The signals are 
separated by only 2.56 MHz. While the RF filter’s pass 
band was only 2 MHz wide, the cutoff was not sharp 
enough to attenuate the emitted harmonic. This harmonic 
affected each of the amplifiers located before the mixer. 
Once the incoming signal is mixed down to 35.42 MHz, 
it is no longer susceptible to the aggressor. 

Physical separation also affects the magnitude of 
interference. As seen Figure 8, only the RF1 chain which 
was located physically “above” the processor was 
seriously affected. Even though RFO was located above 
several FPGAs, it was only slightly affected by the 
interference. 



Figure 8: Diagram of relative location of components. 

So how was the aggressor generated? 

The scan-out signal is part of a twelve bit scan bus output 
used for factory boundary-scan testing. The processor 
uses scan-in and scan-out signals to test internal 
functions, and verify transactions. Once the processor is 
deemed “good,” the scan bits are no longer needed. There 
are several instructions the manufacturer recommends that 
the user perform to keep them disabled. According to the 
datasheet, the user should disable the signals through 
software. The user is also instructed to leave the output 
pins unconnected. Both of these instructions were 
followed. 

The team contacted the manufacturer to ask if this 
unwelcomed spur was a common occurrence, and 
determine if there was way to mitigate the problem. The 
manufacturer was able to successfully recreate the 
conditions in their lab, and also saw the same symptoms 
on their processor’s scan-out pins. Even though they were 
able to study the problem, they were unable to provide a 
solution to removed the spurs. 

Mitigation 

Although there was no ready solution to remove the 
jamming signal, a way had to be found to mitigate the 
problem. The RF chain had an excess of gain. Each chain 
had approximately 50 dB of onboard amplification. The 
rest was off board (located in the antenna’s LNA). The 
gain was needed to implement an Automatic Gain Control 
(AGC) circuit, which could attenuate any excess gain 
using digital step attenuators (DSAs). Because each 
amplifier was allowing the signal to get into the chain, 
one was removed. This reduced the gain to 37 dB. While 





it reduced the dynamic range of the AGC, it did not take 
away from the system as a whole. 

Additionally unshielded passive components on the RF 
daughtercard were swapped with shielded versions, if 
available. This improved the magnitude of the jamming 
frequency, as shown below. 
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Figure 9: Location of mitigated spurs in PSD chart. 

As a result of the mitigation techniques, the LHCP chain 
(RF Chain 0 - which performs weak signal acquisition) no 
longer had any spurs above or in the pass band centered at 
2.652 MHz. Only one spur was located below the noise 
floor, but it did not degrade the weak signal acquisition. 
The RHCP chain (RF Chain 1) still had one spur above 
the noise floor. Because that chain was only performing 
fast acquisition, its performance also was not degraded. 

Lesson Learned: 

When there is a substantial amount of gain in the design, 
be sure to look beyond the first few harmonics of your 
frequencies. Perform a complete frequency analysis of the 
system. Limit the number of clock frequencies in your 
system, and ensure that harmonics of base frequencies 
will not appear near or in the pass band of the receiver’s 
RF chain. If it appears that frequencies may be close to 
one another, discuss mitigation plans ahead of time. 

Ensure that the outputs of any digital circuit are set to low 
slew (the slowest transition rate). Also ensure that high 
speed digital signals are properly terminated. Un- 
terminated high slew signals produce reflections, and 
cause noise on power and ground lines. 

OSCILLATOR VIBRATION FAILURE 

Transporting any payload into orbit puts a tremendous 
amount of physical stress on a system. It is imperative to 
ensure that space design can survive the conditions 
experienced during a launch. In space, a damaged piece of 



equipment is often no more useful than a piece of bent 
metal. Therefore, every component of the final design 
must be exposed to launch-like accelerations while still on 
the ground. 

In October 2007, the team prepared the completed space 
flight Navigator GPS Receiver for vibration testing. The 
goal was to shake the design while it was powered on and 
operational. A GPS signal generator ran an orbital 
simulation and sent analog RF data through a coaxial 
cable to the receiver. A power supply provided the 28 
volts DC necessary for the design. The Navigator GPS 
receiver generated telemetry data through a high speed 
serial RS644 connection. This serial connection was the 
only means to monitor the functionality of the system 
while under test. 

The receiver was mounted to a Ling Dynamic Systems’ 
Model 730-335 vibration system. This shaker table 
consists of coiled wire, a magnet, a very powerful cooling 
fan, and a PC interface. It behaves as a large low 
frequency vertical speaker. The unit is capable of 
generating 75 G PE ak of acceleration, to a vertical 
displacement of up to 2.0 inches (peak to peak). The 
vibration frequency can range from DC to 3 kHz. It can 
place a maximum force of 8800N (2000 lbf). There are 
different table adapters to allow space instruments to be 
shaken in the X, Y or Z dimensions. The PC controls the 
acceleration profile to which a system is exposed. 



Figure 10: Navigator GPS tested on shaker table. 



The Navigator space flight unit was exposed to three 
difference profiles: sine sweep, sine burst, and random 
vibration. The random vibration consisted of three 
different levels: 25%, 50%, and 100% of the required 14.1 
Grms- 

The telemetry data was monitored to verify nominal 
operation of the receiver throughout the test. The 
following table describes the outcome of the test in the X 
dimension: 


Test 

Result 

Sine Sweep (.25 G) 

Pass 

Sine Burst (22 G) 

Pass 

Random Vibration (25%) 

Pass 

Random Vibration (50%) 

Pass 

Random Vibration (100%) 

Loss of telemetry 


Table 2: Results of Vibration Tests 


When the telemetry was lost from the receiver, the test 
was discontinued. No further tests were performed that 
day. The system was returned to a Electro-static 
Discharge (ESD) controlled space-flight qualified lab and 
was disassembled for inspection. 

It was discovered that the system’s Oven Controlled 
Crystal Oscillator (OCXO) had an interior mechanical 
failure. When the part was removed from the board, an 
engineer stated “when you shook the OCXO, it sounded 
like a baby rattle.” 

The oscillator was picked because its family was listed as 
space flight qualified. The acceleration rating on the part 
was 20 G rms . 

So why did the part fail? 

Two engineers were responsible for ordering and 
qualifying the OCXO. Traditionally, this is the 
responsibility of a parts engineer. However, because of 
budgetary restrictions, no parts engineer had been 
assigned to the team. During the post failure analysis, 
both engineers were interviewed. They picked the part 
due to the space rating and due to its frequency stability 
which were claimed in the datasheet. The engineers 
wanted to verify that the OCXO performed as expected. 
So they contacted the manufacturer, ordered five units 
and specified the frequency as 65.536 MHz. 

The data sheet claimed the following properties: 


OCXO 

220 221 Series 

Radiation Hardness 

60 Krads (Si) TID 

Pyroshock tested 

Yes 

Vibration 

20 Grms (Minimum) 

Shock test 

1 000 G peak 

Lead Time 

1 8-22 weeks 

Warranty 

Two Year 


Table 3: OCXO Datasheet 


An additional information flyer provided the following 
information about the physical dimensions: 


OCXO 


220 221 Series 


Package Type 


16 pin DIP 


Pin Type 


Through Hole 
Surface Mount 


( 220 ) 

( 221 ) 


Physical Dimensions 


.975”L x .800” W x .500”H 


Warm Dp Time 


Less than 5 minutes 


Applications 


GPS Receivers 


Table 4: OCXO Second Datasheet 


Apparently the two datasheets can refer to different parts 
(a space-flight part and a commercial equivalent) based 
on a suffix to the family part. This information was not in 
the datasheet. In order to specify whether the part is a 
space flight grade OCXO, the vibration and radiation 
grades must be specified. Both versions have the same 
family number. 

Although engineers A and B were evaluating the 
oscillator, engineer A (who was the one who actually 
ordered the part) believed that they were only ordering the 
part to evaluate it. Because of this, he did not include any 
space characteristics in the list of requirements. Neither 
engineer knew that there were two versions of the 
oscillator. 


When the part arrived, engineer A verified that it 
functioned properly with the system. It provided an 
appropriate amount of frequency stability. When engineer 
B received the properly functioning part, he assumed that 
it was space-rated, as described in the datasheet. In reality 
the received part was a pin-compatible commercial 
equivalent to the space-flight part. 

Upon discovering the error, the team ordered the correct 
space flight qualified OCXOs. As a result of how late in 
the development process the failure was discovered, the 
manufacturer accelerated the assembly and the shipping 
of the parts. The Navigator team was then able to 
successfully perform the vibration test of the system. 

Lessons Learned: 


1. Large teams generally consist of smaller specialized 
groups. Ensure everyone on the team knows what the 
development plan will be for the entire system. 


















2. Be careful when using special-order components. Try 
to evaluate the actual part which will be used. If parts are 
being evaluated against related parts, ensure that everyone 
knows when the transition will be made to the final part. 
Don’t forget to verify the final part. 

3. If the design is complex and the budget allows for it, 
have a dedicated parts engineer to verify that every 
component in the system meets the same minimum 
requirements. Create tables that show which parts have 
met the requirements, and which haven’t. 

RF FPGA VIBRATION FAILURE 

After the OCXO failure, further system testing and 
inspection was performed. This inspection revealed that 
the FPGA on the RF Daughtercard also had several 
failures. The pins had broken near the point where they 
connect to the top of the FPGA. These breaks appear as a 
clear separation from the connection point to the FPGA. 



Figure 11: Photo of the pin broken 


The FPGA was an Actel RT32SXA space rated FPGA, 
containing 208 pins running 52 on each edge of the chip. 
This chip had a RT prefix to the part number, ensuring 
that there is no ambiguity about its space rating. Even 
with this rating, it was discovered that 32 pins had broken. 

So why did the part fail? 

First, a brief history on the component: This FPGA is one 
that can generate a fair amount of heat during use. Since 
convection cooling is not an option in space (because 
there is no air to move), the only way to cool the part is 
through conductive cooling (taking the heat from the chip 
and passing it to the circuit board by physical contact). 

In order to improve the conductive cooling, the 
manufacturer placed a thermal plate on the bottom of the 
FPGA. This plate is designed to quickly remove the heat 
from the body of the chip. Not only is the plate thermally 
conductive, but it is also electrically conductive. This is a 


well understood way of removing heat, but (if it isn’t 
handled well) could electrically connect many unrelated 
signals on the board. Therefore, a gel must be used which 
is a good conductor of heat, and also an electrical 
insulator. 
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Figure 12: Location of Nusil under FPGA 


Board designers began using a thermal adhesive called 
Nusil. Nusil has the appropriate electrical and thermal 
properties needed. An added benefit of this thermal 
adhesive is that after it is in place for 24 hours, it 
alleviates stress during vibration by acting as a strong 
glue. 

There are two requirements to achieve this benefit. The 
first is to place a primer on the bottom of the chip and on 
the circuit board. Without the primer, the thermal 
adhesive is not able to stick to anything. The second, 
sufficient Nusil must be used to cover 80%-90% of the 
bottom area of the FPGA. 

During post-failure analysis, it was discovered that primer 
was not placed on the FPGA or the board. Secondly, 
Nusil only covered 40% of the area under the part. Upon 
further analysis, it was discovered that there was not 
enough documentation. A technician who was not 
familiar with the process of using primer in these situation 
assembled the board. Finally, due to accelerated 
schedules, the Board left the lab with only a minor 
inspection. 

Lessons Learned 

Don’t let aggressive schedules cause your team to 
overlook details. Ensure that any special procedures are 
well documented. Engineers who are familiar with 
techniques have tendencies to forget details. 
Documentation is even more important, when involving 
engineers who are unfamiliar with the processes. 

RF AMPLIFIERS FOOTPRINT FAILURE 

During the unit test of the RF Daughtercard, the RF 
engineer tested the resistance between the power plane 
and the ground plane. His equipment measured it as a 
short. He needed to find out what was causing the 




electrical connection between the two independent 
voltages. 

During his testing, he was measuring an unplaced 
amplifier. This amplifier, which was not on the board, 
also measured a short between its power pin and its 
ground pin. Initially, he believed that it was a bad part. 
After measuring three identical parts, he realized that all 
had the same internal short. He then unsoldered this 
family of parts from the RF Daughtercard. There was no 
longer a short on the board. 

So why did this family of parts fail? 

These parts were a semi-custom order. The dies were 
commercial silicon, which were up-screened for the 
temperature specifications of the mission. These silicon 
dies were then placed in space flight packages. 

During the ordering process, the point of contact at the 
company provided the technical information for the 
family. In an email, he gave the RF designer a datasheet 
of a similar amplifier and informed the designer that the 
company would make the electrical and mechanical 
design of the new part to be the same as this related 
amplifier. 

He was apparently unaware that it would be different. 

Of the eight pins on the amplifier, the Power (which is 
also RF-Out), the RF-ln and the ground pins were at 
locations other than what was described in the datasheet. 

Expected Pin Location Actual Pin Location 

RF in ' 

GND 

GND 

GND 


Figure 13: Pin locations of the supplied amplifier. 

The RF engineer contacted the company to determine 
what had happened. In an emailed response, the point of 
contact acknowledged the company had changed the pin 
locations without informing him, but he did not know 
what was the rationale. He offered to replace any 
damaged parts. 

To verify the correct pin locations, the team needed to 
“dead bug” the amplifier. Dead bugging a part generally 
means that the component is glued to the board with its 
pins (the legs) up in the air. Wires are manually soldered 
onto these dead bug legs. 


After verifying the correct pin location, the team needed 
to refabricate the printed circuit board with the correct 
footprint of the amplifier. 

Lessons Learned 

When ordering custom parts, allow enough time to test 
and fix any unforeseen problems. If possible, it is very 
helpful to test the custom part independently on a bread- 
board or wire-wrap board, before you commit your 
printed circuit board to that design. 

SUMMARY 

New technologies drive our industry. When implementing 
these new designs, we know that there is a tremendous 
amount of validation and debugging to ensure a stable 
product. There are many problems that can be 
experienced: 

First of all, the most important and recurrent theme in this 
paper has been the need to validate that each component 
in the system behaves as the designer intended it. 
Identifying higher risk components early, and allowing 
time to ensure their characteristics, is an important 
responsibility. Sufficient testing should also be performed 
on the integrated product to verify that the components do 
not create any unwanted side affects to other portions of 
the system. 

Secondly, we have found that the effort invested (early in 
the design process) into making testing easier, offers time 
savings throughout the entire development and debugging 
process. Ensure that the designers know what tools they 
will have available to them during the development 
portion (such as logic and spectrum analyzers) so that 
they may take advantage of those tool when creating their 
design. 

Third, when dealing with suppliers of intellectual 
property, remember that the goals of the supplier may not 
be the same as yours. If they are unable to meet your 
needs, it can be very beneficial to either go to another 
supplier, or build it in-house. You may also find a 
member of your team to design the item instead, as long 
as that member understands the functionality you wish to 
purchase. 

Finally, there are certain challenges which can be 
predicted in a development cycle, and some which can 
not. It is necessary to incorporate extra time into 
development schedules. Designs may not be error free on 
the first attempt. Give your team some amount of time to 
fix these unexpected problems. 
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